In a Linux system, a container can provide lightweight virtualization to isolate processes from resources. The container can effectively group resources managed by a single operating system into isolated groups, so as to better balance conflicting resource usage requirements among the isolated groups. Compared with other virtualization solutions, this solution requires neither instruction-level simulation nor just-in-time compilation. The container can locally execute an instruction in a core central processing unit (CPU) without any special interpretation mechanism, thereby avoiding complexity of paravirtualization and system call replacement.
A method for creating and entering a container is provided, and therefore an application program runs on a Linux operating system as an independent machine while sharing many underlying resources. The container provides isolation and also reduces overheads by sharing resources. Therefore, the overheads of the container are much less than that of real virtualization.
Referring to FIG. 1, a Linux container (LXC) starts an application program according to a command, such as lxc-start . . . [command], entered by a user, and the procedure is as follows:
A container start process creates a new container, and exists as a daemon of the container at the same time.
The container start process creates an application start process, and puts the application start process into the container for execution; and then the application start process initializes the container according to a command line parameter entered by a user.
The application start process starts, according to a command entered by the user by using a command line, an application program in the container, where a process of the application program is an initial (init) process in the container.
When another application program needs to be put into the container for execution, the application program needs to be started outside the container first, and a list of process identities (PIDs) of the application program is obtained; and then a PID of a current process is written into a control file to migrate a process execution environment to the container, so that the application program is executed in the container with a granularity of a process.
After a container destroying command is called, a container daemon exists as a container destroying process. The container daemon obtains a group identity (ID) of a process group in the container by using socket communication, and sends a SIGKILL signal to the process group in the container by using a kill( ) system call to terminate the process group in the container. After the container daemon detects termination of the init process in the container, the container daemon exits, and the container is destroyed.
In the foregoing existing method for starting an application program in a Linux container, only one application program can be started when a container is created, and if an additional application program needs to be started in the container, the application program needs to be started outside the container first, and then a process of the application program is put into the container for execution. Therefore, the operation is complex, and an execution environment of the application program is changed during operation. Furthermore, if the application program that needs to be started additionally is a multi-process application, PIDs of all processes of the application program need to be obtained, and a PID of the current application process is manually written into a control file for multiple times, which requires a system administrator using the container to be quite familiar with the application program so as to complete the foregoing operation that is complex and has a high probability of error. In addition, when some processes of the application program are inside the container while some processes are outside the container, a fault in the application program may be caused due to isolation of the container.